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Copyright Notice 
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Abstract 
This memo discusses earlier allocation of code points by IANA as a 
remedy to the problem created by the "Standards Action" IANA policy 


for protocols for which, by the IETF process, implementation and 
deployment experience is desired or required prior to publication. 


1. Introduction 


In Standards Track RFCs, there is often a need to allocate code 
points for various objects, messages, or other protocol entities so 
that implementations can interoperate. Many of these code point 
spaces have registries handled by the Internet Assigned Number 
Authority (IANA). Several IANA allocation policies are described in 
RFC 2434 [2434]. Some of them, such as First Come First Served or 
Expert Review, do not require a formal IETF action before the IANA 
performs allocation. However, in situations where code points are a 
scarce resource and/or the IETF community is willing to retain tight 
control of the protocol, policies such as IESG Approval, IETF 
Consensus, or Standards Action have been used. The Standards Action 
policy represents a problem in situations where implementation and/or 
deployment experience are desired or required for the Standards 
Action. 


To break the deadlock, "pre-RFC" implementations have sometimes 
simply chosen some "Seemingly unused" code points; these may turn out 
to be different from those later assigned by IANA. To make matters 
worse, these "pre-RFC" implementations are often deployed. This 
creates several potential interoperability problems between early 
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implementations and implementations of the final standard, as 
described below: 


1. IANA allocates code points different from those that early 
implementations assumed would be allocated. Early implementations 
won’t interoperate with standard ones. 


2. IANA allocates code points used silently for other extensions. 
Different extensions will collide. 


This gets in the way of the main purpose of standards; namely, to 
facilitate interoperable implementations. 


It is easy to say that pre-RFC implementations should be kept private 
and should not be deployed; however, both the length of the standards 
process and the immense value of early implementations and early 
deployments suggest finding a better solution. As an example, in the 
case of documents produced by Working Groups in the Routing Area, a 
pre-RFC implementation is highly desirable and sometimes even 
required, and early deployments provide useful feedback on the 
technical and operational quality of the specification. 


This memo proposes that, under strictly controlled circumstances, 
TANA make an early allocation of code points. The memo lays out the 
conditions for early allocation, as well as the process to be 
followed; it also says how these allocations are dealt with in the 
event of a failure in the process (such as the RFC not being 
published). 


This memo only addresses the early allocation of code points from 
spaces whose allocation policy is "Standards Action" [2434] AND that 
have been amended to permit early allocation. This permission must 
be granted by the IESG, and code spaces with permission for early 
allocation must be marked as such in the IANA registry. 


2. Conditions for Early Allocation 


The following conditions must hold before a request may be made for 
early allocation of code points: 


a) The code points must be from a space designated as "Standards 
Action", amended by IESG approval to permit Early Allocation. 


b) The format, semantics, processing, and other rules related to 
handling the protocol entities defined by the code points 
(henceforth called "specifications") must be adequately described 
in an Internet draft that is proposed as Standards Track. 
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c) The specifications of these code points must be stable; i.e., if 
there is a change, implementations based on the earlier and later 
specifications must be seamlessly interoperable. 


d) There is sufficient interest in early (pre-RFC) implementation and 
deployment in the community. 


If conditions (a) or (b) are not met, then the processes in this memo 
do not apply. 


3. Process for Early Allocation 


There are three processes associated with early allocation: making 
the request for code points; following up on the request; and 
revoking an early allocation. It cannot be emphasized enough that 
these processes must have a minimal impact on IANA itself, or they 
will not be feasible. 


The processes described below assume that the document in question is 
the product of an IETF Working Group. If this is not the case, 
replace "WG chairs" below with "shepherding Area Director". 


3.1. Request 


The process for requesting and obtaining early allocation of code 
points is as follows: 


1) The authors (editors) of the document submit a request for early 
allocation to the Working Group chairs, specifying which code 
points require early allocation and which document they should be 
assigned to. 


2) The WG chairs determine whether the conditions for early 
allocations described in section 2 are met; particularly, 
conditions (c) and (d). 


3) The WG chairs gauge whether there is consensus within the WG that 
early allocation is appropriate in the case of the given document. 


4) If it is, with the approval of the Area Director(s), the WG chairs 
request IANA to make an early allocation. 


5) IANA makes an allocation from the appropriate registry, marking it 
as "temporary", valid for a period of one year from the date of 
allocation. The date of allocation should also be recorded in the 
registry and made visible to the public. 
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Note that Internet Drafts should not include a specific value of a 
code point until this value has been formally allocated by IANA. 


3.2. Follow-Up 


It is the responsibility of the document authors and the Working 
Group chairs to review changes in the document, and especially in the 
specifications of the code points for which early allocation was 
requested, to ensure that the changes are backward compatible. 


If at some point changes that are not backward compatible are 
nonetheless required, a decision needs to be made as to whether 
previously allocated code points must be deprecated (see section 3.3 
for more information on code point deprecation). The considerations 
include aspects such as the possibility of existing deployments of 
the older implementations and, hence, the possibility for a collision 
between older and newer implementations in the field. 


If the document progresses to the point at which IANA normally makes 
code point allocations, it is the responsibility of the authors and 
the WG chairs to remind IANA that there were early allocations, and 
of the code point values so allocated, in the IANA Considerations 
section of the RFC-to-be. Allocation is then just a matter of 
removing the "temporary" tag from the allocation description. 


3.3. Expiry 


If early allocations expire before the document progresses to the 
point where IANA normally makes allocations, the authors and WG 
chairs may follow an abbreviated version of the process in section 
3.1 to request renewal of the code points. At most, one renewal 
request may be made; thus, authors should choose carefully when the 
original request is to be made. 


As an exception to the above rule, under rare circumstances, more 
than one allocation renewal may be justified. All such renewal 
requests must be reviewed by the IESG. The renewal request to the 
IESG must include the reasons why such renewal is necessary, and the 
WG’s plans regarding the specification. 


If a follow-up request is not made, or the document fails to progress 
to a Standards Track RFC, the WG chairs are responsible for informing 
IANA that the code points are to be marked "deprecated" (and are not 
to be allocated). The WG chairs are further responsible for 
informing IANA when the deprecated code points can be completely de- 
allocated (i.e., made available for new allocations). 
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In particular, it is not IANA’s responsibility to track the status of 
allocations, their expiration, or when they may be re-allocated. 


Note that if a document is submitted for review to the IESG and at 
the time of submission some early allocations are valid (not 
expired), these allocations should not be expired while the document 
is under IESG consideration or waiting in the RFC Editor’s queue 
after approval by the IESG. 


4. IANA Considerations 


This document defines procedures for early allocation of code points 
in the registries with the Standards Action policy and as such 
directly affects IANA functions. 


5. Normative References 


[2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA 
Considerations Section in RFCs", BCP 26, RFC 2434, October 
1998. 


6. Security Considerations 


It is important to keep in mind ’'denial of service’ attacks on IANA 
as a result of the processes in this memo. There are two that are 
immediately obvious: depletion of code space by early allocations and 
process overloading of IANA itself. The processes described here 
attempt to alleviate both of these, but they should be subject to 
scrutiny to ensure this. 
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Full Copyright Statement 
Copyright (C) The Internet Society (2005). 


This document is subject to the rights, licenses and restrictions 
contained in BCP 78, and except as set forth therein, the authors 
retain all their rights. 


This document and the information contained herein are provided on an 
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 


Intellectual Property 


The IETF takes no position regarding the validity or scope of any 
Intellectual Property Rights or other rights that might be claimed to 
pertain to the implementation or use of the technology described in 
this document or the extent to which any license under such rights 
might or might not be available; nor does it represent that it has 
made any independent effort to identify any such rights. Information 
on the IETF’s procedures with respect to rights in IETF Documents can 
be found in BCP 78 and BCP 79. 


Copies of IPR disclosures made to the IETF Secretariat and any 
assurances of licenses to be made available, or the result of an 
attempt made to obtain a general license or permission for the use of 
such proprietary rights by implementers or users of this 
specification can be obtained from the IETF on-line IPR repository at 
http://www.ietf.org/ipr. 


The IETF invites any interested party to bring to its attention any 
copyrights, patents or patent applications, or other proprietary 
rights that may cover technology that may be required to implement 
this standard. Please address the information to the IETF at ietf- 
ipr@ietf.org. 
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